home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5696 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.0 KB  |  89 lines
  1. Path: magnus.acs.ohio-state.edu!csn!ub!newserve!rebecca!rpi!not-for-mail
  2. From: jamshid@io.com (Jamshid Afshar)
  3. Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.tools.mfc,comp.lang.c++.moderated
  4. Subject: Re: Newbie question: default op=
  5. Followup-To: comp.os.ms-windows.programmer.tools.mfc,comp.lang.c++.moderated
  6. Date: 5 Feb 1996 21:28:46 -0000
  7. Organization: Illuminati Online, Austin, Texas, USA
  8. Sender: cppmods@netlab.cs.rpi.edu
  9. Approved: vandevod@cs.rpi.edu
  10. Message-ID: <4f5sqe$dgm@netlab.cs.rpi.edu>
  11. References: <30FEA0B4.4F66@ymi.com> <4dmrdu$niv@news2.aimnet.com>
  12. NNTP-Posting-Host: netlab.cs.rpi.edu
  13. X-Original-Date: 20 Jan 1996 13:01:30 -0600
  14.  
  15. { Note that follow-ups are to c.l.c++.m and c.o.m.p.tools.mfc -mod }
  16.  
  17. In article <4dmrdu$niv@news2.aimnet.com>, Dan Howard  <dhoward@kset.com> wrote:
  18. >Sadly, you are correct.  You do need to write an explicit operator =()
  19. >because the compiler 
  20. >does not provide one.  Yes, the compiler should be able to figure it out but
  21. >it isn't in the 
  22. >Draft ANSI C++ Specification so too bad.
  23.  
  24. No, since at least 1990 when the ARM (Stroustrup's _Annotated C++
  25. Reference Manual) was first printed, C++ has required the compiler to
  26. generate a default assignment operator which calls the base class
  27. assignment operator then does a member-wise assignment.  This is not
  28. (necessarily) the same as a bit-wise copy.  This default assignment
  29. operator is not generated if any base class has a non-public
  30. assignment operator.  The original poster was probably deriving from
  31. MFC's CObject, which declares CObject::operator=() as private, hence
  32. he had to explicitly define his derived class's operator=().  The docs
  33. imply that this was done on purpose.  Don't necessarily take anything
  34. you see in the MFC as good or modern C++ code design practices.
  35.  
  36. >If you want an even worse problem, the copy constructor automatically
  37. >provided by compilers 
  38. >does a bit-copy rather than a member-by-member copy.  Thus, no copy
  39. >constructors are called in 
  40. >the following code:
  41.  
  42. Again, this was true in early versions of C++ and with a few early
  43. compilers, but since the ARM the default copy constructor has done
  44. member-wise initialization, not a bit-wise copy.
  45.  
  46. >class stupid { CString x; };
  47. >
  48. >void main() {
  49. >   stupid a;
  50. >   stupid b(a);  // try stepping into this line, 
  51. no CString::CString(const CString& s) called
  52. >}
  53.  
  54. I believe Borland's first C++ compiler (c. 1990) implemented this
  55. correctly, so I would be surprised if Micrsoft's Visual C++ has this
  56. bug (and it takes a lot to surprise me when it comes to MS's C++
  57. implementation).
  58.  
  59. >Jeffrey Keays <keays@ymi.com> wrote:
  60. >>I am trying to use the &*%$ MFC collections [...]
  61. >>I have this general C++ question.
  62. >>Why is it making me create operator= functions for assignment of the same
  63. >>type (or instance / reference of the same type).  The class I'm trying to
  64. >>assign has no pointers or anything that would require special handling.  
  65.  
  66. You wouldn't have this problem if you didn't derive from MFC's
  67. CObject.  Actually, using Smalltalk-like Object-based classes is
  68. widely regarded as bad C++ class design.  You might try using MFC
  69. 4.0's template collections; they're a little better, but still pretty
  70. bizarre and poorly/incorrectly documented.
  71.  
  72. Again, I can't stress enough to C++ programmers to not consider MFC an
  73. example of good C++ class design.  Btw, if you do use CArray<T> note
  74. that it does not define an assignment operator (you have to use a
  75. Copy() member function) and note that the docs are incorrect about the
  76. template functions ConstructElements(T* arr, int nCount) and
  77. DestructElements(T* arr, int nCount).  You do not have to specialize
  78. them -- they call the constructors/destructors, but you do have to
  79. specialize an UNDOCUMENTED template function CopyElements(T* dst, T*
  80. src, int nCount) because it defaults to a *bit-wise* copy.
  81.  
  82. Jamshid Afshar
  83. jamshid@io.com
  84.  
  85.       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
  86.       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
  87.       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
  88.       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]
  89.